home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 1 / ETO Development Tools 1.iso / Essentials / C++ AppleLink Messages / CPlus.Dev$ 4⁄27⁄90 / 0111-Constructor Hell-Apr90 < prev    next >
Encoding:
Text File  |  1990-04-27  |  2.2 KB  |  50 lines  |  [TEXT/GEOL]
  1. Item    9255980                         24-April-90        17:46PDT
  2.  
  3. From:   ISAACSON                        Isaacson, Trygve
  4.  
  5. To:     CPLUS.DEV$                      C++ Interest List--Developers
  6.         CPLUS.APPLE$                    C++ Interest List--Apple Employees
  7.  
  8. Sub:    Constructor Hell
  9.  
  10. Attn: CPLUS.DEV$
  11. Attn: CPLUS.APPLE$
  12. SentBy: Trygve Isaacson
  13. Date   4/24/90
  14. Subject    Constructor Hell
  15. From   Trygve Isaacson
  16. To CPLUS.APPLE$, CPLUS.DEV$
  17.  
  18. REGARDING                Constructor Hell
  19. Don, I see three basic ways to "solve" the problems with constuctor failure.
  20.  
  21. One approach is to do essentially what your example showed:  use a validation
  22. routine that checks to see if the constructor succeeded.  Note however that
  23. the example code, as is, is potentially deadly.  If the 'free store instance'
  24. can't be allocated, p will be nil and the call to 'p->Validate()' may die a
  25. horrible death or may return true!
  26.  
  27. A second approach, which I think is better, is to NOT do anything in the
  28. constructor;  actually, I guess that means 'don't use constructors.'  Use the
  29. Validate method to do the initialization and validation, and return a success
  30. or failure indicator (a Boolean, or an error code).  I like the MacApp
  31. convention of naming the init method (it would be IAllocatingClass in your
  32. example).  One problem with constructors is the syntax, which basically
  33. requires that if you create a subclass, the constructor parameters must be a
  34. superset of the parent class' constructor parameters.  By using an explicit
  35. init method, you can define its parameter list however you want (maybe your
  36. subclass takes no init parameters, because it simply specializes the init
  37. parameters to the parent class).
  38.  
  39. A third approach is, as you suggested, to use an exception-handling mechanism.
  40.  I think that the 'don't use constructors' rule can still apply here.  This is
  41. what MacApp does.  If you're using MacApp, this is great; I think you can even
  42. use MacApp's exception handling for non-PascalObjects.  If you're not using
  43. MacApp, a similar mechanism could be implemented.  If you look at the source
  44. code to UFailure, you'll see that MacApp's exception-handling mechanism is
  45. actually quite straightforward.  And it works well.
  46.  
  47. Not a Fan of Constructors,
  48. Trygve Isaacson
  49.  
  50.